home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / bridge / bridge-minutes-92jul.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  8.8 KB  |  271 lines
  1. Editor's Note: Minutes received 7/22 
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Fred Baker/ACC
  7.  
  8. Minutes of the Bridge MIB Working Group (BRIDGE)
  9.  
  10. The Group met for three purposes:
  11.  
  12.  
  13.   1. To discuss IEEE 802.5's changes to their MIB, and its impacts on
  14.      the MIB described in RFC 1286.
  15.  
  16.   2. To discuss implementation experience with RFC 1286.
  17.  
  18.   3. To determine whether RFC 1286 is ready to advance to Draft Standard
  19.      status.
  20.  
  21.  
  22. Anil Rijsinghani proposed to facilitate convergence with the Source
  23. Routing Addendum to 802.1 by including an optional group for SRT
  24. bridges, called the Source Route Bridge Port Pair Group.  It contains
  25. the following objects:
  26.  
  27.  
  28. dot1dSrPortPairTableSize
  29.         INTEGER
  30.         "The total number of entries in the Bridge Port Pair Database."
  31.  
  32.  
  33. This number is n(n+1)/2, given that source routing is occurring over n
  34. bridge ports.
  35.  
  36.  
  37. dot1dSrPortPairTable
  38. dot1dSrPortPairEntry [dot1dSrPortPairLowPort, dot1dSrPortPairHighPort]
  39.  
  40. dot1dSrPortPairLowPort  - an Source Route Port Number
  41. dot1dSrPortPairHighPort  - an SOURCE ROUTE Port Number
  42. dot1dSrPortPairBridgeNum - the bridge number used in the Source
  43. Route Descriptor tuple
  44. dot1dSrPortPairState     - "enabled", "disabled", or "invalid"
  45.  
  46.  
  47. Richard Sweat, IEEE 802.5's designated liaison to the Bridge MIB Working
  48. Group, then presented their view of RFC 1286.  To converge with our
  49. work, IEEE 802.5 has deleted or modified a number of its managed objects
  50. and attributes.  They also have some specific requests for changes in
  51. the Source Routing Group of RFC 1286.
  52.  
  53. IEEE 802.5, having already made these changes in its own MIB, suggests
  54. that we:
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62.    o Adopt Anil's Port Pair Group.
  63.  
  64.    o Divide dot1dSrPortHopCountExceededDiscards and dot1dSrPortHopCount,
  65.      which relate to the maximum number of routing descriptors in an All
  66.      Paths Explorer (APE) or Spanning Tree Explorer (STE) frame, into
  67.      two maxima and two counters:  one each for APEs and STEs.
  68.  
  69.    o Extend dot1dSrPortLargestFrame (which is an enumerated integer with
  70.      8 values) to have 64 possible values as described in draft 7 of the
  71.      Source Route Addendum.
  72.  
  73.    o Count occurrences of duplicate LAN IDs or Tree errors, in an effort
  74.      to detect problems in networks containing older IBM Source Routing
  75.      Bridges.
  76.  
  77.    o Count LAN ID Mismatches (cases where a frame is being forwarded,
  78.      but the ``from'' LAN ID is incorrect.
  79.  
  80.    o Instead of counting frames in and frames out, count frames through
  81.      a device.  This applies to dot1dSrPortSpecInFrames,
  82.      dot1dSrPortSpecOutFrames, dot1dSrPortApeInFrames,
  83.      dot1dSrPortApeOutFrames, dot1dSrPortSteInFrames, and
  84.      dot1dSrPortSteOutFrames.
  85.  
  86.    o To the dot1dSrGroup, add a scalar read-write variable enumerated
  87.      the same way as dot1dSrPortLargestFrame to indicate the largest
  88.      frame that may pass through the bridge.
  89.  
  90.    o Add a read-write LF Mode field indicating whether the bridge
  91.      operates using older 3 bit length negotiation fields or the newer 6
  92.      bit length field in its RIF.
  93.  
  94.    o Either change the names of objects or include text explaining the
  95.      use of the path type acronyms, as IEEE 802.5 has changed their
  96.      names.  The mapping is:
  97.  
  98.       -  Spanning Tree Explorer (STE) becomes a Spanning Tree Explorer
  99.          (STE).
  100.       -  All Paths Explorer (APE) becomes an All Routes Explorer (ARE).
  101.       -  Specifically Routed Frame (Spec) becomes a Source Routed Frame
  102.          (SRF).
  103.  
  104.  
  105. Fred Baker applauds the efforts of IEEE 802.5 to achieve convergence.
  106. The Working Group felt that the proposals made by Anil and Richard were
  107. basically workable, and drew the following conclusions.  We also felt
  108. (although there were three source routing implementations represented)
  109. that our best expertise was not present at the meeting, and so feel that
  110. the subject should be discussed on the mailing list before reaching a
  111. final conclusion.
  112.  
  113.  
  114.                                    2
  115.  
  116.  
  117.  
  118.  
  119.  
  120. The Group's initial conclusions were:
  121.  
  122.  
  123.    o Adopt Anil's Port Pair Group.
  124.  
  125.    o The Group is not sure of the necessity of dividing the hop counts
  126.      and hop count discards by APEs and STEs.
  127.  
  128.    o Extend dot1dSrPortLargestFrame (which is an enumerated integer with
  129.      8 values) to have 64 possible values as described in draft 7 of the
  130.      Source Routing Addendum.
  131.  
  132.    o Count occurrences of duplicate LAN IDs or Tree errors, in an effort
  133.      to detect problems in networks containing older IBM Source Routing
  134.      Bridges.
  135.  
  136.    o Count LAN ID Mismatches (cases where a frame is being forwarded,
  137.      but the ``from'' LAN ID is incorrect.
  138.  
  139.    o Do not change the way we count frames, as our implementations do in
  140.      fact count them (IEEE was concerned that these could not be
  141.      counted), and this method is consistent with other IETF MIBs.
  142.  
  143.    o To the dot1dSrGroup, add a scalar read-write variable enumerated
  144.      the same way as dot1dSrPortLargestFrame to indicate the largest
  145.      frame that may pass through the bridge.
  146.  
  147.    o Add a read-write LF Mode field indicating whether the bridge
  148.      operates using older 3 bit length negotiation fields or the newer 6
  149.      bit length field in its RIF.
  150.  
  151.    o Include text explaining the use of the path type acronyms.
  152.  
  153.  
  154. The Group then moved on to discuss implementation experience.  Six
  155. vendors indicated that they had implemented the MIB, and were largely
  156. happy with it.  The following suggestions for clarification were made:
  157.  
  158.  
  159.    o Anil will provide clarifying text for the DESCRIPTION of
  160.      dot1dStpPortPathCost, which some have found inadequate.
  161.  
  162.    o The Default Value of dot1dStaticAllowedToGoTo be specified in the
  163.      DESCRIPTION as a string of ones of appropriate length.
  164.  
  165.    o The Default Value of dot1dStaticStatus is ``permanent''.
  166.  
  167.    o Port Numbers use the range 1..65535.
  168.  
  169.    o Update the bibliography.
  170.  
  171.  
  172.                                    3
  173.  
  174.  
  175.  
  176.  
  177.  
  178.    o dot1dTpPortInFrames and dot1dTpPortOutFrames be clarified by
  179.      changing the last few words in the description from ``processed by
  180.      the local bridging function'' to ``processed by the bridging
  181.      function, including management frames.''
  182.  
  183.  
  184. We will ask the list to ratify these clarifications.
  185.  
  186. One other issue was raised which affects the strategic direction of this
  187. Working Group.  Some vendors are interested in proxying for IBM Source
  188. Routing Bridges, which use a modified version of the 802.1(d) BPDU.
  189. Also, IEEE 802.1(g) currently proposes that the BPDU be modified in
  190. remote bridges when sent on the lines.  It is quite possible, then, that
  191. a bridge might participate in more than one spanning tree on a port by
  192. port basis.
  193.  
  194. Fred Baker proposed that the object dot1dStpProtocolSpecification, which
  195. indicates a single spanning tree protocol in use in the system, be
  196. deprecated and replaced with an INTEGER bit string indicating the
  197. spanning tree protocols that the device is capable of:
  198.  
  199.  
  200.          1      other
  201.          2      decLb100
  202.          4      ieee8021d
  203.          8      ibmTolkienRing
  204.         16      ieee8021g
  205.  
  206.  
  207. In addition, an object is added to the dot1dStePortEntry indicating
  208. which of those protocols is running on the indicated port.  This allows
  209. for some flexibility.
  210.  
  211. The proposal of the Working Group, given ratification of the above
  212. changes on the list, is that:
  213.  
  214.  
  215.    o The Group do nothing now with IEEE 801.2(g)'s proposals, as it is
  216.      not sufficiently close to completion.
  217.  
  218.    o The Group separate the Source Routing Group into a separate
  219.      document, apply the ratified subset of Anil's and Richard's
  220.      proposals, and recommend that this remain at Proposed Standard
  221.      status.
  222.  
  223.    o The Group apply the requested clarifications and, if ratified,
  224.      Fred's proposed object change, and advance the bulk of the Bridge
  225.      MIB to Draft Standard Status.
  226.  
  227.  
  228. Attendees
  229.  
  230.  
  231.  
  232.                                    4
  233. ^L
  234.  
  235.  
  236.  
  237.  
  238. David Arneson            arneson@ctron.com
  239. Sam Ayers                s.ayers@sybus.com
  240. Fred Baker               fbaker@acc.com
  241. Andy Bierman             bierman@davidsys.com
  242. Greg Celmainis           gregc@newbridge.com
  243. Chris Chiotasso          chris@artel.com
  244. Cathy Cunningham         cmc@microcom.com
  245. David Engel              david@ods.com
  246. Pria Graves              priag@nsd.3com.com
  247. George Kajos             kajos@coral.com
  248. Mark Kepke               mak@cnd.hp.com
  249. Steven Lynes             lyness@rimail.interlan.com
  250. Cindy Mazza
  251. Keith McCloghrie         kzm@hls.com
  252. David Minnich            dwm@fibercom.com
  253. Rina Nathaniel           rina!rnd!rndi@uunet.uu.net
  254. John Payne               jop@wang.com
  255. Venkat Prasad            vsp@3com.com
  256. Guenter Roeck            roeck@conware.de
  257. Michael Sapich           sapich@conware.de
  258. Koichiro Seto            seto@hitachi-cable.co.jp
  259. Timon Sloane             peernet!timon@uunet.uu.net
  260. Chris Sullivan           mm@gandalf.ca
  261. Richard Sweatt           rsweatt@synoptics.com
  262. Stephen Tsun             snt@nsd.3com.com
  263. Luanne Waul              luanne@wwtc.timeplex.com
  264. Gerard White
  265. Kiho Yum                 kxy@nsd.3com.com
  266.  
  267.  
  268.  
  269.                                    5
  270.  
  271.